The invention relates to testing network interconnect devices using test packets containing random data.
Various different types of data networks exist that provide for many types of communications, such as electronic mail, file transfer, web browsing, text chat, and other exchanges of data. With the increased bandwidth and speed of data networks, communications of voice and other forms of real-time, interactive data have also become possible. Examples of the different types of data networks include local area networks (LANs), wide area networks (WANs), the Internet, and so forth.
Terminals and nodes coupled to a data network include various layers, such as layers according to the Open Systems Interconnect (OSI) model. The lowest layer (layer 1) is the physical layer, which is the actual electrical and mechanical interface to the transport medium. The next higher layer (layer 2) is referred to as the data link layer, which is responsible for delivery of information to the transport medium and for error checking the information. The next layer (layer 3) is referred to as the network layer, which is responsible for the switching and routing of the connection. Other layers are also part of the OSI model.
One example of a layer 2 protocol is the Ethernet protocol, with one version specified in the 802.3 Standard from the Institute of Electrical and Electronics Engineers (IEEE). One example of a layer 3 protocol is the Internet Protocol (IP).
An Ethernet frame includes a destination address, a source address, payload data, and a cyclic redundancy check (CRC) field (for error detection). The payload data of the Ethernet frame carries a layer 3 datagram, such as an IP datagram. An IP datagram also includes a protocol header and a payload. The IP header includes a source network address, a destination network address, control flags, a protocol field to indicate the next level protocol used in the payload of the IP datagram, a header checksum that is calculated based on the content of the IP header, and other information.
A data network includes a number of switches or routers to enable communication of data between endpoints. Packets that are communicated over the data networks contain addresses that are used by switches or routers to forward or route packets to the appropriate path for delivery to the destination
When a switch or router is manufactured, it is run through a variety of tests. Many of these tests involve sending test packets from a test generator, with the test packets passed through the switch or router under test. The switch or router under test forwards the packets to a receiving test device, which determines if the packets contain errors or not. In conventional test systems designed for verifying some layer 2 switches, a simple check for CRC errors is usually sufficient to identify data corruption. Since many layer 2 switches do not change the contents of packets passing through the switches, the original CRC of the test packet remains unchanged as it passes through the system under test (assuming data corruption did not occur in the system under test). At the receiving end, the receiving test device can simply perform a CRC error detection to determine if data corruption has occurred.
At the transmitting end of every Ethernet system, the CRC value placed into a packet is calculated at the OSI data link layer based on the bit pattern of the Ethernet frame (including the source address, destination address, and payload). At the receiving end of every Ethernet system, the CRC of a received frame is re-calculated to check for errors in transmission. If any of the bits of the destination address, source address, or payload, changes value in transit, then the CRC check performed at the receiving end is designed to indicate that data corruption has occurred. The check at the receiving end is performed at the data link layer by concatenating the data pattern and the CRC bits, with the concatenated bit pattern divided by a preselected divisor polynomial P (which is also used at the transmitting end to generate the CRC bits). If the division produces no remainder (that is, the remainder is zero), then the CRC algorithm provides a reliable indication that no errors have occurred.
Although CRC checking is quick and easy to perform in hardware, and is relatively accurate with layer 2 switches that do not change the content of the test packet, such testing may be insufficient if the switch or router under test is capable of changing the content of test packets, such as the content of the IP header. Some layer 2 switches are able to modify contents of the IP header, such as to change type of service information or to add or change virtual local area network (VLAN) tags. A layer 3 switch or router almost always changes the content of the packet header. Usually the layer 3 switch or router changes the destination and source addresses in the header as well as recalculates a new checksum due to the change of the header. Another type of switch that may cause contents of packets to change is a switch including Asynchronous Transfer Mode (ATM) core device.
When the switch or router under test modifies the content of a packet, a new CRC value is calculated for the modified packet before the switch or router under test transmits the packet to the receiving test device. Thus, at the receiving test device, performance of the CRC error detection will merely indicate if the CRC value generated by the switch or router under test was correct for the data transmitted. The CRC protects against data corruption for the transport medium from the switch or router under test to the receiving test device. However, simple CRC checking at the receiving test device does not enable confirmation regarding whether the switch or router under test performed error-free processing of the packet. Even if the switch or router under test is defective and performs packet header transformations incorrectly, the CRC value calculated by the medium access control (MAC) module in the switch or router under test will still be correct, since the calculated CRC is based on the incorrect packet content. As a result, simple CRC checking does not enable verification of the content of the packet which has been processed by a switch or router under test.
A need thus exists for an improved testing apparatus and method.
In general, according to one embodiment, a system to produce a test packet for testing a system under test comprises a storage unit containing a target check value and a header field representing a header of the test packet after transformation by the system under test. A random data generator is adapted to generate random data for inclusion in the test packet. A controller is adapted to derive a splice value for inclusion in the test packet, the splice value being based on the header field, target check value, and the random data.
Some embodiments of the invention may have one or more of the following advantages. Verification of test packet content can be performed in tests involving systems or devices that are capable of transforming packet content, such as the header of the packet. The verification can be performed efficiently and at relatively high speed. In some arrangements, the verification of packet content can be performed at substantially wire speeds so that the system or device can be tested at high packet transfer speeds. Also, by being able to use test packets containing random data, a more comprehensive testing procedure can be implemented.